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This  report  describes  a  recently  developed  technique  for  the  rapid 
realization  of  compilers  for  new  source  languages  and  new  target  machines. 

The  method  is  built  around  a  table-driven  translation  algorithm, 
which  was  announced  some  time  ago*.  This  algorithm  is  embodied  In  a 
small  general-purpose  (language-  and  machine -independent)  program,  called 
the  "Translater",  which  accepts  strings  of  characters,  syntactically 
analyzes  them,  and  emits  pseudo-code  macro-instructions,  performing 
arbitrarily  complex  investigations  of  syntactic  context  to  decide  this 
emission. 

The  Translater  is  particularized  to  a  given  source-target  pair  by  a 
set  of  tables  which  define  the  syntax  of  the  source  language  and  the 
strategy  to  be  used  in  studying  context  and  emitting  macros.  The  newly- 
developed  toohnlque  consists  of  the  creation  of  a  readable,  formal  language 
l:or  describing  both  the  syntax  and  the  strategy  of  macro  generation;  thus, 
the  Translater  can,  by  translating  a  message  in  this  new  language,  create 
an  instance  of  its  own  tables. 

This  capability  of  the  Translater  is  formally  trivial  and  would  be  of 
little  interest,  were  it  not  that: 

1.  That  portion  of  the  language  which  defines  syntax  corresponds 
very  closely  with  the  "Backus  normal  form"  and  can  be  trans^ 
llterated  almost  directly  from  any  conventional  formal  description 
of  syntax. 

2.  That  portion  of  the  language  which  deals  with  the  strategy  of 
macro  emission  is  fairly  powerful  and  rather  surprisingly 
readable . 

In  the  sequel,  we  first  sketch  the  Translater  algorithm  sufficiently 
well  to  introduce  the  critical  control  tables.  Then  we  describe  the  gross 


*S.  Warshall,  *'A  Syntax  Directed  Generator",  Proceedings  of  the  EJCC, 
1961,  Macmillan  and  Co.,  1961, 
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strategy  of  the  "bootstrap"  operation  and  finally  define  the  language  in 
which  new  compilers  are  defined  to  the  bootstrap. 

A  pictorial  representation  of  the  syntax  of  the  new  language  for 
translation  description  and  a  sample  "program"  in  that  language  (describing 
the  translation  of  a  conventional  algebraic  language)  are  supplied  as 
appendices . 
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The  Translater  is  a  general-purpose  program  which  accepts  strings  in 
a  source  language,  syntactically  analyzes  them,  and  emits  a  sequence  of 
messages  (which  we  call  "macros");  the  selection  and  emission  of  these 
messages  may  be  triggered  either  by  very  local  syntactic  recognition  or 
by  rather  complex  investigation  of  syntactic  context. 

The  emission  of  a  macro  actually  consists  of  two  activities:  the 
construction  of  a  macro  descriptor  and  the  call  of  a  separate  program  (called 
the  In-Sequence-Optimlzer,  or  "ISO")  which  accepts  and  processes  the 
descriptor. 

The  Translater  is  general-purpose  in  the  sense  that  it  is  capable 
of  syntactic  analysis  of  any  of  a  wide  class  of  languages  and  of  imple¬ 
menting  any  of  a  wide  class  of  decision  procedures  for  controlling  macro 
emission  by  investigation  of  syntactic  context.  This  generality  is  achieved 
by  the  use  of  tables  which  define  the  syntax  of  the  source  language  and 
tables  which  define  the  decision  procedure.  The  Translater  itself  is  a 
relatively  straightforward  program  which  simply  accepts  a  source  language 
message  and  uses  the  tables  to  process  it. 

The  "syntax  tables"  may  be  viewed  as  a  coded  representation  of 
some  standard  formal  definition  of  a  language's  syntax  (for  example,  the 
Backus  notation).  Similarly,  the  second  set  of  tables  —  which  we  will 
call  "generation  strategy  tables"  —  nay  be  viewed  as  an  encodement  of 
a  class  of  statements  defining  the  decision  procedure.  It  is  well  known 
that  a  common  formalism  may  serve  for  the  definition  of  any  of  the  usual 
programming  languages  and  thus  the  possibility  of  using  a  standard  program, 
with  different  tables  for  different  languages,  is  clear.  However,  the 
existenoe  of  a  convenient  formalism  for  describing  generation  strategy  — 
and  thus  the  possibility  of  a  general-purpose  algorithm  controlled  by  a 
tabular  encodement  of  a  strategy  —  is  by  no  means  as  obvious. 

We  have  devised  such  a  formalism,  which  is  adequate  to  describe 
fairly  complex  strategy  more  oc  less  concisely. 


The  nature  of  the  formalism  In  turn  implies  a  table  design  and  an 
associated  algorithm  — the  "generator"  —  controlled  by  the  tables. 

The  essential  trick  in  the  development  of  this  formalism  is  the 
use  of  a  tree -representation  of  the  source-language  message  (which  is 
the  "natural"  output  of  an  analyzer).  This  tree -representation  provides 
a  convenient  domain  over  which  to  define  both  contextual  constraint  and 
macro  emission. 

The  formalism  for  describing  generation  strategy  is  itself  a  lan¬ 
guage  "generation  strategy  language"  —  and,  in  particular,  a  language 
descrlbable  in  the  Backus  notation.  This  suggests  the  interesting  possibility 
of  a  "bootstrap"  compilation.  That  is,  if  one  were  to  construct  by  hand. 

1 .  A  set  of  tables  which  define  the  syntactic  structure  of  (say) 
the  Backus  notation  (BNF)  and  the  generation  strategy  lan¬ 
guage  (GSL); 

2.  A  set  of  tables  which  define  the  generation  strategy  for 
Inspecting  tree-representations  of  BNF  and  GSL  formulas  and 
emitting  macros; 

3.  An  algorithm  which  accepts  these  macros  and  interprets  them 
as  orders  to  build  lines  of  a  set  of  translator  control  tables; 

Then  one  might,  by  putting  this  latter  program  in  place  of  the  ISO, 
use  the  compiler  to  create  Instances  of  the  tables  which  control  it. 

In  fact  this  is  precisely  what  has  been  done.  A  program  called 
the  "Bootstrap  BO"  creates,  by  processing  macros,  a  set  of  prototypes 
of  the  control  tables;  then,  after  the  entire  BNF-GSL  message  has  been 
processed  an  additional  set  of  algorithms  converts  these  prototype  tables 
to  final  form.  Since  the  actions  performed  by  the  Translater  in  executing 
the  bootstrap  translation  are  a  proper  subset  of  those  it  is  capable  of 
performing,  and  since  the  bootstrap  runs  better  if  the  Translater  can  do  a 
few  things  in  a  slightly  different  way,  the  Translater  is  "tuned"  (slightly 
altered)  in  the  bootstrap  version;  however,  it  is  essentially  the  same, 
standard  universal  algorithm. 


The  remainder  of  this  report  is  divided  into  two  sections.  Section 
k  describes  how  the  Translater  works;  Section  B  defines  the  bootstrap 
Translator  by  sketching  the  fimction  of  the  Bootstrap  ISO  and  defining  the 
formalism  BNFGSSL  **-  the  language  which  the  bootstrap  Translater  in  fact 
translates. 


A.l. 


The  Storage  of  Syntax  Rules 

The  formal  languages  In  which  we  are  interested  may  all  be 
described  (to  within  some  special  trickery  for  certain  "small"  types, 
like  character  strings)  in  the  metallnguistlcs  of  the  ALGOL  60  report* 
which  has  been  called  "b.n.f."  (for  Backus  normal  form).  That  is, 
each  type  is  defined  by  a  statement  consisting  of  the  name  of  the  type 
enclosed  by  the  signs  "<"  and  ">"  followed  by  the  sign  "i;="  followed 
by  a  description  of  the  alternative  rules  for  forming  the  type,  separated 
from  each  other  by  the  sign  Each  of  these  rules  is  in  turn  formed  by 

concatenating  "components"  in  the  order  in  which  they  must  be  found  to 
satisfy  the  rule.  A  component  is  given  either  by  enclosing  a  type  name  in 
the  signs  "<!'  and  ">"  or  by  explicitly  giving  the  exact  symbols  of  the  source 
alphabet  to  be  recognized.  Naturally,  the  metalinguistic  signs  are  all 
excluded  from  the  source  alphabet. 

Thus,  each  type  may  for  our  purposes  be  viewed  as  given  by  a 
form  like: 

<type>  ::=  C2  |  Cj^  ^5  I  ^3 

where  the  represent  either  types  or  specific  strings  of  characters. 

The  right-hand  side  of  such  a  statement  may  be  represented  by  a 
binary  tree  in  which  nodes  correspond  to  components .  The  right  son.  of  a 
node  is  the  next  component  in  the  rule  and  the  left  son  is  the  first  compo¬ 
nent  of  the  next  alternative  rule.  Thus,  the  example  would  be  represented 
by: 


(We  will  conventionally  draw  right  sons  to  the  right  and  left  sons 
below,  in  order  to  simplify  layout.) 


*"Report  on  the  Algorithmic  Language  ALGOL  60",  Naur(ed.)et  al. 
Communications  of  the  Association  for  Computing  Machinery.  Vol.  3, 
No.  5,  May,  1960 


This  naturally  suggests  the  application  of  the  distributive  law  to 
shorten  the  statement  and  thus  the  tree.  The  right-hand  side  of  the 
example  means,  conceptually,  Cj  (C2  |  Cg)  | 
and  the  corresponding  tree 


is  what  we  clearly  wish  the  analyzer  program  to  work  with.  After  all,  the 
successful  recognition  of  a  followed  by  a  failure  to  recognize  a 
should  lead  directly  to  an  attempt  to  recognize  a  instead  of  a  C2. 
rather  than  a  re -investigation  of  alternatives  to  the  entire  formation. 

It  sometimes  occurs  that  one  formation  for  a  type  looks  precisely 
like  another  followed  by  some  additional  component(s) .  Thus,  we  Introduce 
a  special  symbol  into  the  tree,  which  indicates  successful  completion  of 
a  formation  even  though  a  failure  to  continue  it  was  encountered.  This 
mark,  which  we  will  designate  by  “T"  and  call  the  "terminal"  mark,  is 
found  only  as  a  left  son  and  may  not  have  sons  Itself. 

Example; 


=  1  =2  =3  I 


[Remarks  It  appears  to  be  true  of  the  source  languages  with  which  we  are 
dealing  that  one  is  always  safe  looking  for  the  longest  formation  for  a  type 
first  and  this  assumption  is  made  in  order  to  shorten  and  simplify  the 
analyzer  algorithm.] 

Recursive  Definitions 

If  the  definition  of  a  type  R  includes  a  formation  whose  first 
component  is  R,  we  call  that  formation  "left  recursive";  we  define  "right 
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recursive"  analogously.  We  specifically  exclude  any  formation  which 
mentions  R  twice,  although  we  permit  an  arbitrary  number  of  formations  of 
R  to  mention  R  once.  Left  and  right  recursive  definitions  are  not  stored 
as  written,  but  are  revised  to  eliminate  explicit  mention  of  R. 

Let  us  assume  that  a  definition  has  been  appropriately  reordered 
so  that  it  may  be  expressed  as,  for  example: 


T 


The  essential  features  of  this  reordering  are  as  follows: 

1.  There  is  only  one  node  N^,  representing  R  on  the  left; 
has  no  left  son. 

2.  The  tree  is  really  two  distinct  trees  connected  through 

3.  All  nodes  representing  R  (except  for  N^)  are  in  the  upper 
tree  with  right  sons  of  zero. 

We  process  this  tree  as  follows: 

1.  Take  the  right  son  of  (denoted  N^). 

2.  Erase  (setting  left  son  of  its  father  to  zero). 

3.  Take  every  node  representing  R;  replace  it  by  a  "null  type" 
and  set  its  right  son  to  the  trunk  of  the  tree. 

4.  Take  every  node  whose  right  son  is  zero  and  set  its  right 
son  to  N^. 


5.  Take  every  node  whose  left  son  is  T  and  set  Its  left  son  to 

Ni- 

6.  Beginning  with  take  left  sons  until  a  node  N2  is 
encountered  with  left  son  of  zero.  Set  left  son  of  N2  to 
T. 

The  effect  of  all  this  processing  is  to  command  a  re-6ntry  of  the 
trunk  for  all  right  recursives  until  a  successful  formation  has  been  effected. 
Then,  using  the  left  recursive  formations,  efforts  are  made  to  extend  it  as 
long  as  possible. 
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A.  2. 


The  Storage  of  Generation  Strategy 

Generation  strategy  is  stated  in  terms  of  the  nodes  of  a  tree 
representation  of  a  source  language  formula,  and  is  composed  as  follows: 

1.  A  set  of  rules  for  distinguishing  kinds  of  node  is  given. 

Nodes  are  naturally  distinguished  by  the  syntactic  types 
they  represent;  they  may  be  further  distinguished  by  their 
syntactic  context. 

2.  Each  distinct  kind  of  node  is  assigned  a  short  sequence  of 
commands.  Each  command  either  defines  an  action  to  be 
performed  (like,  for  example,  the  emission  of  a  macro)  or 
names  another  node  of  the  tree. 

The  generator  algorithm  starts  at  the  trunk  of  the  tree  and  walks 
from  node  to  node,  at  each  node  pausing  to  execute  a  command  assigned  to 
that  kind  of  node  •  If  the  command  indicates  an  action,  that  action  is  per¬ 
formed;  if  it  names  another  node,  the  generator  moves  to  that  node.  Upon 
each  successive  consideration  of  a  node,  the  next  command  in  that  node's 
sequence  of  commands  is  considered.  Whenever  a  considered  node  has  no 
commands  left,  control  moves  automatically  to  the  node's  father  in  the  tree. 

Some  actions  have  variables  of  call,  which  may  be  (among 
other  things)  the  names  of  nodes  of  the  tree.  These  names  and  the  names 
of  nodes  given  as  commands  and  the  names  of  nodes  given  in  the  context 
descriptions  are  all  expressed  by  "relative  tree  names"  —  that  is.  by 
rules  for  getting  from  any  given  point  of  the  tree  to  some  other.  These  rules 
take  the  form  of  a  sequence  of  steps.  Each  step  is  either  the  name  of  a 
"neighbor"  (e.g..  FATHER.  SON  3)  or  of  some  line  item  of  a  node. 

Typical  relative  tree  names  might  be: 

FATHER  *  RTS  IB  *  SON  2 
SON  2  *  SON  3  *  SON  1 

At  any  given  moment  a  relative  tree  name  is  interpreted  with 
respect  to  the  node  which  the  generator  is  currently  considering. 
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A.  3. 


Organization  of  the  Translater  Program 

The  Translater  is  controlled  (after  initialization)  by  a  syntactic 
analyzer  called  ANALVZ. 

ANALYZ  is  entered  with  a  syntactic  "goal":  to  recognize  some 
specific  syntactic  type,  starting  at  a  specified  character  of  the  input 
string.  Initially,  the  goal  is  "program",  or  its  equivalent,  and  the 
starting  character  is  the  first.  Every  goal  leads  either  to  a  new  goal 
(if  the  current  type  is  defined  in  terms  of  another  type)  or  to  an  inspection 
of  the  input  to  find  either  a  specific  symbol  string  (stored  in  SSLIST),  one 
of  a  finite  set  of  specific  symbol  strings  (stored  in  SSLIST),  or  one  of  a 
class  recognized  by  a  special  scanner  (e.g.,an  identifier  or  an  Integer). 
When  a  goal  is  found  to  be  impossible  to  meet,  the  analyzer  consults  the 
syntax  tables  SYNTRE  and  SYNPT  and  either  sets  up  an  alternative  goal  at 
the  same  point  of  the  input  string  or,  if  there  are  none,  backs  up  the 
string  to  try  an  alternative  interpretation  of  previous  material. 

Whenever  a  syntactic  type  which  has  been  marked  as  "big"  enough 
to  call  the  generator  (see  B.  5.)  is  completely  recognized,  a  call  on  the 
generator  code,  GENRAT,  is  made.  During  the  course  of  recognition,  a 
tree-representation  (OUTREE)  of  the  structure  of  that  syntactic  type  was 
constructed . 

GENRAT  starts  at  the  node  (OUTREE  line)  which  represents  the 
syntactic  type  which  caused  the  GENRAT  call.  At  each  node  which  it 
considers,  GENRAT  calls  PREDIC  to  decide  what  kind  of  node  it  is. 

The  algorithm  PREDIC,  using  two  control  tables,  considers  both 
the  syntactic  type  of  the  node  and  the  nature  of  its  context.  The  first 
of  these  control  tables,  PREDPT,  contains  an  entry  of  each  different 
kind  of  node.  All  kinds  which  are  cases  of  the  same  syntactic  type  are 
stored  contiguously  in  PREDPT  and  are  pointed  to  by  the  SYNPT  line  for 
that  type.  Each  line  of  PREDPT  points  in  turn  to  the  second  control  table, 
PRDCAT,  in  which  is  stored  a  list  of  (contextual)  predicates  to  be  satisfied 
before  the  node  is  adjudged  to  be  of  that  kind.  At  the  end  of  each  list  of 
predicates  in  PRDCAT  is  a  pointer  to  the  list  of  activities  for  nodes  of 
that  kind  (see  below). 


Given  PREDlC's  result,  GENRAT  proceeds  to  do  whatever  need  be 
done  at  nodes  of  that  type  on  the  n-th  occasion  they  are  considered. 
(GENRAT  control  keeps  track  of  the  current  value  of  n  for  each  node). 

Lists  of  activities  associated  with  different  kinds  of  nodes  are 
found  in  the  table  SEQIST.  These  activities  either  consist  of  transfer 
of  consideration  to  another  node  or  of  a  set  of  actions  to  be  performed. 

If  the  latter,  the  set  of  actions  is  listed  in  the  table  ACTION.  If  any 
action  has  variables  of  call,  these  are  listed  in  the  table  GVBI^T.  The 
routine  ACT  controls  the  execution  of  required  actions. 

Some  actions  Involve  the  transmission  of  information  to  the 
optimizer.  This  is  generally  accomplished  by  putting  the  Information  into 
a  communication  table  called  SHPIST  and  calling  the  optimizer  (ISO).  Some 
of  this  Information  requires  a  certain  amount  of  interpretation  before  being 
placed  on  SHPIST.  The  routine  PUTVBL  interprets  certain  kinds  of  encoded 
variable  descriptions  (found  in  GVBIST)  and  places  its  result  in  SHPIST. 


Organization  of  the  Control  Tables 


B. 

The  Language  BNFGSL 

The  language  BNFGSL  Is  a  vehicle  for  defining  to  a  "universal" 
compiler  the  particular  translation  it  is  to  effect.  A  trans later  definition 
written  in  BNFGSL  falls  naturally  into  two  main  sections:  first,  a  formal 
description  of  the  source  language,  and  second,  a  description  of  the 
"generation  strategy"  for  getting  from  recognized  constructs  in  the  source 
language  to  corresponding  computational  commands. 

The  source  language  description  controls  a  syntactic  analysis 
whose  output  is  a  tree  representation  of  the  recognized  structure  (called 
OUTREE).  When  a  "big"  enough  structure  has  been  recognized,  a  call 
upon  a. generator  is  made.  The  generation  strategy  description  is  written 
in  terms  of  a  walk  through  this  tree  and  has,  as  its  central  notion,  the 
idea  of  a  "relative  tree  name",  by  which  we  mean  a  rule  for  getting  from 
the  current  node  of  the  tree  to  some  other  node. 


B.l. 


The  Definition  of  a  Source  Lanauaoe 

A  language  description  Is  composed  of  a  set  of  "type  definitions" 
each  of  which  defines  a  single  syntactic  typ>e  of  the  source  language. 

In  general,  a  syntactic  type  is  defined  by  a  set  of  '‘formations",  or  ways 
to  form  a  representative  of  that  type  from  smaller  structures.  There  may 
be  several  alternative  ways  to  form  a  type  and  thus  a  type  definition  may 
include  several  formations.  Each  formation  is  made  up  of  a  sequence  of 
"components"  which  are  to  be  concatenated  to  satisfy  the  formation.  A 
component  is  either  the  name  of  some  syntactic  type  or  a  fixed  symbol 
string . 

In  BNFGSL,  we  use  arbitrary  identifiers  to  denote  the  names  of 
syntactic  types.  Fixed  symbol  strings  are  written  by  the  following  rule: 
First  write  the  character  "$".  Then  write  the  characters  of  the  desired 
symbol  string,  unless  one  of  them  is  either  "$"  or  "/"  or  a  blank.  In 
the  latter  case,  precede  each  such  character  by  a  "$".  The  entire  string 
is  delimited  by  blank  or  "/".  We  begin  a  type  definition  by  writing  first 
the  name  of  the  type  being  defined,  then  the  character  then  each 
of  the  components  of  the  first  formation  in  order,  then  the  character  "/  ", 
then  each  component  of  the  second  formation,  then  another  "/",  and  so  on 
until  there  are  no  more  formations;  then  we  write  "  // " . 

Examples: 

MULOP  =$*/$$/// 

AREX  =  TERM  /AREX  ADOP  TERM  // 

In  addition  to  the  set  of  formations  for  the  type,  we  require  that 
certain  additional  Information  be  given  as  part  of  the  type  definition.  This 
additional  material  is  given  in  the  form  of  a  list  of  "tags",  separated  by 
commas,  following  the  "//",  and  delimited  by  "/".  The  list  of  allowable 
tags  and  their  meaning  is  as  follows: 


FDCLST  - 


TLUAn  (where 

GENRAT  - 

INHIBT  - 

METAGN  - 

ASSIGN  • 

INVOKE  - 


This  type  is  defined  by  formations  each  of  which  has 
one  component  only,  and  that  component  is  a  fixed 
symbol  string. 

n  is  an  integer)  -  This  type  is  defined,  not  by 
explicit  formations,  but  by  a  special  scanner  — 
specifically,  the  n-th  such  scanner. 

This  type  is  big  enough  syntactically  to  warrant  a 
call  upon  the  generator. 

This  type  is  such  that,  while  the  analyzer  is 
endeavoring  to  recognize  it  completely,  no  generation 
may  occur  (even  if  there  is  complete  recognition  of 
types  which  normally  cause  generation). 

This  type  is  such  as  to  trigger  a  call  upon  the 
generator;  however,  the  purpose  of  that  call  is  to 
process  a  declaration  rather  than  to  produce  any  code. 
This  type  is  such  that  once  it  has  been  completely 
processed,  any  PRTECT's  effected  during  its  pro¬ 
cessing  may  be  disregarded  (see  discussion  of 
PRTECT,  below). 

Frequently,  in  the  course  of  syntactic  recognition,  a 
substantial  tree  structure  will  be  built  in  OUTREE. 
composed  of  a  great  many  nodes  of  purely  formal 
interest  buried  among  which  is  a  single  interesting 
identifier.  For  example  the  simple  construct  "(A)" 
might  lead  —  through  the  syntax  of  many  familiar 
languages  —  to  the  structure: 


arithmetic  expression 

I 

term 

\ 

factor 

^  i 

(arithmetic  expression) 

i 

term 

I 

factor 

i 

identifier:  A 

Later  on<  during  generation,  it  would  be  convenient  to  minimize 
investigation  of  this  deceptively  complex  tree.  The  analyzer  can  detect 
these  situations  —  if  given  a  few  hints  —  by  carrying  some  of  the 
properties  of  the  components  of  each  formation  up  to  the  node  of  the  type 
being  formed.  The  requisite  hint  is  that  those  types  which  represent  the 
variables  of  discourse  (identifiers.  Integers,  and  strings,  for  example) 
or  unary  operators  (addition  operators,  for  example,  if  they  may  be  unary) 
be  tagged  with  "INVOKE".  This  will  cause  the  automatic  marking  (during 
analysis)  of  each  node  as  either  "HARD"  or  "EASY"  according  as  the 
subtree  trunked  by  that  node  does  or  does  not  include  at  least  two  nodes 
of  "INVOKE"  type.  Loosely  speaking,  "INVOKED  types  are  such  that  exactly 
those  structures  containing  more  than  one  of  them  require  some  code 
generations . 

NULTYP  -  A  "null  type"  is  a  type  with  no  formations  and  is 
always  successfully  recognized  without  using  up 
any  characters. 

The  "language  definition"  section  of  a  translator  definition  consists 
of  a  set  of  type  definitions  bracketed  by  the  strings  "BNF. and  "/BNF", 
respectively 


That  structure  In  OUTREE  which  corresponds  to  any  type 
recognition  may  be  deduced  from  its  formations.  Thus  if  a  type  is 
given  by: 

A  =  BC/BCD/E/// 

and  an  A  is  in  fact  re  cognized «  the  resulting  structure  would  be  one  of 
the  following: 

/\  /N  1 

That  is  to  say,  the  sons  of  a  node  correspond,  1-1  and  in  order,  to 
the  components  of  one  of  its  formations,  with  two  exceptions. 

1.  If  a  type  is  marked  FDCLST,  nodes  which  correspond  to  it 
will  be  terminal  (have  no  sons). 

2.  If  a  formation  is  either  left  recursive  or  right  recursive, 

it  will  result  in  a  "bush”  of  components  at  the  same  level 
in  the  tree,  with  no  explicit  mention  of  the  recursive  type. 
Example: 

ADOP  =  $  +  /$-//  FKLST  / 

AREX  =  IDENT/AREX  ADOP  IDENT/// 
leads  to  the  following  representation  of  "A  +  B  +  C  -  D": 


(5)  (0)  (6)  (0)  (7)  (1)  (8) 

We  refer  to  the  nodes  for  the  set  of  components  of  a  type  as  the 
"sons”  of  the  node  for  that  type,  numbered  from  left  to  right.  We  call  the 
(n+1)®^  son,  the  "right  sibling"  of  the  n^*'.  The  meaning  of  "father"  and 
"left  sibling"  is  the  obvious  one. 


The  OUTREE  actually  contains  a  good  deal  of  information  at  each 
node  in  addition  to  a  code  for  the  syntactic  type  represented.  Most  of 
this  information  is  set  and  used  by  the  compiler  for  its  own  internal 
purposes.  Some  items  however  are  either  used  or  set  (or  both)  as  a 
result  of  explicit  indicators  in  the  BNFGSL;  these  will  be  discussed  below. 
For  the  moment,  we  merely  remark  that  one  item  of  a  node,  called  "NR", 
always  contains  the  appropriate  one  of  the  following; 

1.  The  number  of  sons,  if  the  node  is  not  terminal. 

2.  The  line  number  in  the  symbol  table,  the  literal  table, 

or  the  table  of  fixed  symbol  strings,  corresponding  to  the 
node. 

3.  The  relative  number  (starting  with  0)  of  the  formation, 
if  the  node  represents  a  fixed  list  (FKIST  type). 

The  parenthesized  figures  in  the  previously  given  tree  are  NR 
values,  assuming  that  "A",  "B",  "C",  "D"  are  in  lines  5,  6,  7,  8  of  the 
symbol  table,  respectively.  Neither  the  identifiers  themselves  nor  the 
BCD-representatlons  of  "+"  and  are  carried  explicitly  in  the  nodes. 


B.3. 


The  Definition  of  a  Generation  Strategy 


The  "generator  definition"  section  of  a  translator  description  is 
composed  of  a  set  of  "generation  statements"  bracketed  by  "GSL. and 
"  /GSL" ,  re  spe  ctlve  ly . 

Each  generation  statement  begins  with  a  "condition"  to  be  satis¬ 
fied;  then  there  follows  (after  a  delimiting  a  set  of  activities  to  be 
performed  if  the  condition  is  satisfied.  A  condition  begins  with  "IF" 
followed  by  either  the  name  of  a  syntactic  type  or  a  fixed  symbol  string. 
Then  there  may  be  an  arbitrary  number  of  additional  "predicates"  to  be 
satisfied.  The  different  predicates  are  concatenated  with  "AND"s;  that 
is,  they  must  be  satisfied  in  order  for  the  condition  to  be  met. 

There  are  six  kinds  of  predicates,  which  are  as  follows  (where, 
by  "<K  >"  we  mean  any  representative  of  the  type  R  and  in  particular,  by 
"<r.t.n.>"  we  mean  any  relative  tree  name); 


Tm 

1.  Zero  test 


■fsm., 

<r.t.n.>  =  0 


2 .  Syntactic  type 
test 


<r.t.n.>  X  =  0 
<r.t*n.>  IS 
<identifler> 


3.  Symbol  test  <r.t.n.> - 

<fixed  symbol 
string> 


Meaning 

True,  if  the  named  node  is 
on  the  tree. 

Converse 

True,  if  the  syntactic  t  3 
of  the  named  node  is  as 
indicated . 

True,  if  the  named  node  is 
precisely  the  string  indicated; 
it  is  assumed  that  the  node 
will  represent  either  a  fixed 
symbol  string  or  some  syntactic 
type  tagged  with  "FKLST"  or 
an  identifier. 


Ixss. 

Form 

Meaning 

Complexity 

<r.t.n.>  IS  HARD 

Tests  the  named  node  for  the 

test 

<r.t.n.>  IS  EASY 

property  described  in  the 

section  on  the  tag  "INVOKE", 

above . 

NR  test 

NR(<r.t.n.>)  = 
<lnteger> 

True  if  the  NR  field  of  the 

named  node  has  the  Indicated 

value . 

VTYP  test 

VTYP(<r.t.n.>)  = 
<integer> 

It  would  be  convenient  if 

declared  or  encountered 

propenies  of  the  Indehtifiers 
could  be  discussed  in  BNFGSL. 
In  particular,  it  is  essential 
to  be  able  to  consider  the 
"variety"  of  the  identifier 
(function,  packed  item  name, 
or  whatever),  which  is 
presumed  filled  into  the  VARITY 
item  of  the  symbol  table  by 
the  declaration  processors. 

This  test,  which  is  well- 
defined  only  if  the  named 
node  designates  an  identifier, 
is  true  if  the  VARITY  field  of 
the  SYMTAB  line  number  given 
in  the  NR  field  of  the  named 
node  has  the  required  valuei  . 


Examples: 

IF  TERM  AND  SELF  15  HARD, 

IF  $(  AND  VTYP(I^ATHER*LFTSIB)  =  6, 

IF  VARBLE  AND  SON2  X  »  0  AND  FATHER  IS  FACTOR, 


If  a  given  node  satisfies  several  different  conditions,  it  will  be 
treated  as  though  it  satisfied  the  first  in  order  of  appearance  in  the 
BNFGSL. 

Following  the  condition  and  the  delimiting  is  a  "sequencing 
list"  composed  of  an  arbitrary  number  of  "sequencing  elements"  each 
preceded  by  the  character  The  entire  sequencing  list  is  delimited 

by  a 

A  sequencing  element  is  either  a  single  relative  tree  name  or  an 
"action  list",  by  which  we  mean  a  set  of  "actions"  to  be  performed. 

Each  action  is  given  in  functional  notation;  i.e.,  each  is  composed  of 
an  "imperative"  naming  the  action  followed  by  a  list  of  its  variables  of 
call  separated  by  commas  and  bracketed  by  a  pair  of  parentheses.  Actions 
with  no  variables  of  call  are  given  simply  as  imperatives. 

In  order  to  understand  the  motivation  of  this  section  of  the  language, 
it  Is  helpful  to  view  the  generator  as  at  any  time  considering  some 
particular  node  of  OUTREE  (initially  that  which  triggered  the  GENRAT  call). 

It  Is  this  node  with  respect  to  which  relative  tree  names  are  evaluated. 

A  node  may  be  considered  several  times.  When  the  generator  considers 
a  node  for  the  first  time,  it  is  determined  whether  that  node  .satisfies 
one  of  the  conditions  given  in  the  BNFGSL.  If  it  does,  that  node 
is  set  up  to  perform  the  activities  indicated  in  the  sequencing  list 
associated  with  that  condition.  The  first  time  that  node  is  considered, 
it  will  perform  whatever  is  Indicated  by  the  first  sequencing  element;  the 
second  time,  the  second  element;  and  so  on.  If  an  element  is  simply  a 
relative  tree  name,  the  generator  will  go  on  to  consider  the  node  named  by 
that  element.  CXherwise,  the  generator  will  cause  the  execution  of  all 
the  actions  on  the  action  list  which  comprises  that  element. 

If  a  sequencing  element  is  a  relative  tree  name  and  if  that  name  is 
not  well-defined  with  respect  to  the  node  currently  being  considered,  the 
generator  moves  to  the  next  sequencing  element. 

If  we  have  run  out  of  sequencing  elements  for  a  node  or  if  a  node 
never  meets  any  condition  in  the  first  place,  subsequent  attempts  to  consider 
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that  node  will  always  lead  to  immediate  consideration  of  its  father.  If  that 
node  is  the  node  which  triggered  generation,  the  automatic  walk  to  its 
father  is  the  signal  which  causes  return  of  control  to  the  analyzer. 

The  Imperatives  are  as  follows: 

OUTPUT  -  This  has  a  variable  number  of  arguments,  but  at 

least  one;  its  effect  is  to  throw  out  onto  a  communi¬ 
cation  table  (SHPIST)  all  the  arguments  in  order  and 
then  execute  a  call  upon  the  ISO.  The  first  argument 
position  is  conventionally  used  to  transmit  the  name 
of  the  macro-instruction  being  output.  Thus, 
OUTPUT(SWITCH,SON3,  NR(SON5)). 


PUTVIA  - 
PUTVLB  - 
OUTPOT 


PUTNAM  - 


LABEL  - 


MINE  - 


PUTVLA  places  its  single  argument  in  the  first  line 
of  the  communication  table  SHPIST,  PUTVLB  places 
its  single  argument  in  the  next  free  line  of  SHPIST. 
OUTPOT  acts  like  OUTPUT,  except  with  no  arguments. 
Both  PUTVLA  and  PUTVLB  interpret  their  arguments  as 
values  (see  discussion  of  MINE,  below). 

This  places  the  OUTREE  line  number  of  its  single 
argument  on  the  next  free  line  of  SHPIST. 

This  causes  the  current  point  in  the  output  to  be 
labeled  with  the  Identifier  given  by  its  single  argument. 
Example: 

LABEL(SONl) 

Several  Imperatives  (notably  OUTPUT,  PUTVLA,  and 
PUTVLB)  give  as  arguments  relative  tree  names  whose 
intended  interpretation  is  as  values.  If  a  relative 
tree  name  leads  to  a  terminal  node  denoting  an 
Identifier#  the  interpretation  is  direct.  If,  however, 
it  leads  to  a  non-terminal  node,  this  may  mean  a 
deferred  reference  to  another  terminal  node  (if  the 
non-terminal  node  is  EASY)  or  may  refer  to  the  result 
of  a  previously  output  computation.  This  means  that 
a  certain  amount  of  Interpretation  must  be  done 
automatically  by  the  generator.  In  cxder  to  provide 
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SET 
COPY  . 


enough  information  to  enable  this  interpretation, 
the  generator  follows  all  executions  of  OUTPUT  or 
OUTPOT  by  marking  the  node  whose  consideration 
directed  the  call  with  a  code  number  for  that  line 
of  output.  If  later  some  relative  tree  name  leads 
to  that  node,  the  interpretive  machinery  will  deduce 
(by  inspecting  HARD-EASY  codes,  etc.)  that  this 
node  should  have  led  to  output  and  then  obtain  the 
output  line  number  from  it . 

A  difficulty  arises  when  the  node  N  with  which 
the  output  is  to  be  associated  for  later  interpretation 
is  different  from  the  code  whose  consideration  led 
to  the  output  call .  If  the  tree  structure  is  simply 
such  that  is  the  trunk  of  the  only  interesting 
subtree  of  the  tree  trunked  by  N,  (by  only  "interesting", 
we  mean  that  nothing  outside  it  contains  any  INVOKE 
type  codes) ,  then  the  generator  can  quickly  locate 
the  interesting  and  proceed.  If  this  situation  does 
not  obtain,  however,  some  hint  must  be  given  the 
generator.  The  action  MINE  has  the  effect  of 
associating,  with  the  node  currently  under  consideration, 
the  last  line  which  was  output. 

Example; 

IF  AREX  AND  SELF  IS  HARD, 

$  SONl  $MINE. 

The  result  of  this  would  be  that ,  no  matter  which 
node  in  the  subtree  trunked  by  the  arex  actually 
output  the  last  line  in  the  computation  of  its  value, 
future  interpretation  of  the  arex  node  as  a  value  would 
correctly  be  set  to  the  last  line  of  output. 

Two  fields  are  associated  with  each  node,  which  may 
be  used. to  transmit  OUTREE  line  numbers  from  node  to 
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node.  They  are  called  "TRUE"  and  "FAI5E", 
respectively,  since  they  are  used  commonly  to  pass 
around,  within  a  booldan  expression,  the  true  and  false 
Jump  destinations.  The  ordered  pair  composed  of  these 
two  fields  is  called  "TRUTAB". 

SET  and  COPY  each  has  two  arguments,  of  which 
the  first  is  either  "TRUTH"  or  "FALSTY"  for  both 
and  "TRUTAB"  for  COPY  only.  The  second  argument 
is,  in  all  cases,  a  relative  tree  name.  For  SET,  the 
meaning  is  to  set  the  value  of  the  indicated  field 
(TRUE  for  TRUTH,  FALSE  for  FALSTY)  of  the  node 
currently  being  considered  to  the  OUTREE  line 
number  obtained  by  evaluating  the  relative  tree  name). 
For  COPY,  the  meaning  is  to  copy  the  designated 
field  in  the  named  node  into  the  corresponding  field 
of  the  node  currently  being  considered. 


Examples: 

SET  (TRUTH,  RTSIB*RTSI$) 

COPY(TRUTAB,  FATHER) 

BEGRGN  ")  These  bracket  a  "region";  by  which  we  mean  a 

ENDRGN  (  segment  of  code  suitable  in  size  and  character  as 

a  domain  for  special  register  assignment  optimization. 
These  imperatives  take  no  arguments. 


BEGLUP  /  These  bracket  a  region  which  is  also  a  loop.  Their 

ENDLUP^  effect  upon  the  ISO  is  the  same  as  that  of  BEGRGN 

and  ENDRGN,  save  that  in  addition  a  search  is  made 
for  Invariant  parts  of  the  computation  so  that  they 
may  be  moved  out  of  the  loop.  Nor  arguments . 


BEGRTN 

ENDRTN 

BEGCND 


] 


PRTECT  - 


EXECUT  - 


These  bracket  a  "routine”*  or  file-able  entity*  No 
arguments . 

This  pair  brackets  a  section  of  a  boolean  expreialon 
which  may  be  Jumped  around  (If  booleana  are  handled 
by  conditional  transfers).  Its  purpose  Is  to  prevent 
the  common  subexpression  detectors  In  the  lEO  from 
assuming  that  certain  values  which  mav  be  already 
computed*  always  are.  No  arguments. 

Example:  (The  brackets  indicate  possible  Jumped-over 
regions): 

IF  A  EQ  B+C  OR  B 

This  Imperative  directs  the  ISO  to  prevent  destruotlon 
of  the  current  value  of  Its  single  argument  (whlcdt  must 
be  a  relative  tree  name  denoting  an  identifier)  until 
that  value  is  used.  The  purpose  of  this  device  is  to 
protect  against  situations  where  embedded  assignsMmt 
statements  alter  the  Intent  of  an  arithmetic  ejcpieeslcii 
or  assignment.  For  example*  consider: 

A(I)  =  X  +  (I  =  I  +  1) 

If  the  Intention  Is  for  A(I)  to  be  interpreted  in 
terms  of  the  old  value  of  "I"*  one  can  emit  a 
PRTECT  of  the  node  representing  the  first  "I"  before 
emitting  outputs  which  cause  the  computation  of  the 
righthand  side  of  the  assignment.  The  SO  will  titan 
cause  the  old  "I"  to  be  saved  before  it  is  over¬ 
written  and  reference  the  saved  value  whan  treeUng 
A(I). 

This  provides  a  mechanism  for  ordering  the  run-time 
executlcm  of  an  arbitrary*  independent*  "hend-ooded* 


EQ  C+D  AND  Z  EQ  W+Y,  . . . 
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program.  It  has  one  argument,  the  name  of  the 
program.  The  Bootstrap  assigns  integers  to  the 
Identifiers  which  appear  as  arguments  of  EXECUT  in 
order  of  first  appearance  starting  with  one.  At  run 
time  the  EXECUT  is  interpreted  as  a  Jump  through 
switch  block  to  the  n-th  independent  algorithm,  where 
n  was  the  integer  assigned.  It  is  possible  to  force 
the  numbers  assigned  either  by  giving  the  desired 
Integer  explicitly  as  the  argument  to  EXECUT  or 
(better)  by  initializing  the  table  (EXIPGM)  in  which 
such  identifiers  are  looked  up  and  (appended  if  not 
already  there)  by  the  Bootstrap.  If  it  is  desired  to 
provide  arguments  to  an  independent  algorithm,  they 
can  be  placed  on  SHPIST  by  appropriate  use  of 
PUTVIA,  PUTVLB,  and  PUTNAM. 


B.4. 


Relative  Tree  Names 

A  "relative  tree  name"  is  of  one  of  four  kinds:  either  the  fixed 
string  "SELF"  (meaning  the  node  currently  under  consideration),  the  fixed 
string  "NXTREE"  (meaning  the  trunk  of  the  next  tree  generated  over),  a 
"tree  walk",  or  a  tree  walk  bracketed  by  "LAST("  and 

A  tree  walk  is  a  sequence  of  "steps"  (encoding  requlreinents 
impose  a  practical  limit  on  the  number:  say,  seven),  separated  by 
Steps  are  chosen  from  the  set: 


FATHER  - 
RTS IB  - 
LFTSIB  - 
SONLST  - 
TRUE  - 
FALSE  - 
SON  n  - 

Example: 


father 

right  sibling 
left  sibling 
rightmost  (last)  son 
true  field 
false  field 

son,  where  K  n  a  10 


n 


SONl*SON2 

FATHER  *  RTSIB*TRUE*RTSIB 


The  interpretation  of  such  a  name  is  that  (starting  at  the  node 
under  consideration)  one  executes  the  steps  in  order,  yielding  as  value 
an  OUTREE  line  number.  If  at  any  point  a  step  is  ill-defined  (walkis 
off  the  tree)  ,  the  value  of  the  name  is  set  to  zero. 

If  the  walk  was  bracketed  by  "LAST("  and  ")"  and  also  walked 
off  the  tree,  then  the  value  is  set  to  the  line  number  resulting  from  the 
last  step  which  stayed  on  the  tree. 


B.5. 


Sample  Trans  later  Description 

As  a  brief  example,  let  us  define  an  extremely  simple  language 
translation  in  Bh^FGSL: 

BNF. . 

IDENT  =  //  TLUAl,  INVOKE/ 

TERM  =  IDENT  /  TERM  MULOP  IDENT/// 

AREX  =  TERM  /  AREX  ADOP  TERM/// 

ADOP  =  $+  /  IS  -  //  FIXI5T/ 

MULOP  =  $*/$$/  //  FDCLST/ 

ASGST  =  IDENT  $  =  AREX  $.  //  GENRAT/ 

/  BNF 
GSL. . 

IF  ASGST,  $  SON3  $  OUTPUT  (STORE,  SONl,  SON3). 

IF  AREX  AND  SELF  IS  HARD,  $  SONl  $  MINE. 

IF  TERM  AND  SELF  15  HARD,  SSONl  $MINE  $LFTSIB  $RTSIB*RTSIB. 

IF  TERM,  SLFTSIB  $RTSIB*RTSIB. 

IF  IDENT,  SLFTSIB  $RTSIB*RTSIB. 

IF  ADOP,  SOUTPUT  (ADDSUB,  NR(SELF),  LAST  (LFTSIB*1PTSIB), 

RTSIB)  $RTSIB*RTSIB*RTSIB. 

IF  MULOP,  $  OUTPUT  (  MPYDIV,  NRCSELF),  LAST  (LFTSIB*LFTSIB), 
RTSIB)  $RTSIB*RTSIB*RTSIB. 

/  GSL 

If  the  above  deck  is  input  to  the  Bootstrap,  a  set  of  tables  for  the 
Translator  will  be  generated.  When  the  Translator,  with  that  set  of  tables 
and  an  appropriate  identifier  scanner,  receives  as  input: 

HENRY  =  A*B+C-D*E/F+G. 

it  will  effectively  output  to  the  ISO  the  following: 


1.  MPYDIV,  0,  A.  B 

2.  ADDSUB,  0,  line  1,  C 

3.  MPYDIV,  0,  D,  E 

4.  MPYDIV,  1.  line  3,  F 

5.  ADDSUB,  1,  line  2,  line  4 

6.  ADDSUB,  0,  line  5,  G 

7.  STORE,  HENRY,  line  6 

The  OUTREE  which  is  constructed  by  the  analyzer  will  look  as 

follows: 
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B.5. 


Formal  Description  of  BNFGSL 

This  section  contains  a  description  of  the  translation  of 
BNFGSL  written  in  BNFGSL. 

The  syntax-descriptive  section  of  this  translation  description 
should  be  comprehensible  by  reference  to  the  previous  discussion  of 
BNFGSL.  However,  it  is  difficult  to  understand  the  motivation  for  the 
macros  output  to  the  Bootstrap  ISO  without  at  least  a  sketchy  idea  of 
what  the  latter  algorithm  does  with  thern^ 

.  In  brief,  each  macro  emitted  to  the  Bootstrap  EO  corresponds 

to  a  line  of  one  of  the  seven  prototype  control  tables  being  constructed. 
These  seven  tables  are  prototypes  of  the  following;  respectively: 


1. 

ACTION 

2. 

GVBLST 

3. 

PRDCAT 

4. 

PREDPT 

5. 

SEQIST 

6. 

SYNPT 

7. 

SYNTRE 

The  literal  symbol  table  of  the  bootstrap  compilation  becomes  the 
eighth  control  table,  SSUST. 

The  first  variable  of  call  of  the  OUTPUT  imperative  names,  not 
a  macro,  but  the  number  (1  through  7)  of  that  prototype  table  of  which 
this  call  provides  a  line,  '^he  remaining  variables  of  call  correspond  to 
the  line  items  of  the  line  and  require,  for  their  completer  understanding, 
a  discussion  of  the  tables  of  the  translater  far  too  detailed  for  the  scope 
of  this  report.  It  should  be  noted  however  (by  reference  to  the  picture 
of  table  organization  in  A. 3.)  that  several  tables  contain  line-  items 
which  point  to  other  tables.  The  seven  line  counters  of  the  prototype 
tables  being  built  supiily  the  numbers  of  their  "firstr-unfilled"  '  ^s  to 
the  Bootstrap  ISO  and  thus  this  sort  of  item  need  never  be  given  explicitly. 


BNF.  . 

SYNTYP  =  //  TLUAl  / 

INTGER  =  //  TLUA2  / 

SYMSTG  = //  TLUA37 

LNGDEF  =  $BNF. .  TYPLST  $$/BNF  //GENRAT  / 

TYPI5T  =  TYPDEF /TYPLST  TYPDEF  /// 

TYPDEF  =  SYNTYP  $  =  FSTPRT  SECPRT  //  GENRAT/ 

FSTPRT  =  FORMST  $$/$/  /$$/$/  /// 

SECPRT  =  TAGIST  $$/  /$$/  /// 

TAGLST  =  TAG/TAGI5T  $,  TAG/// 

TAG  =  $INVOKE/$ASSIGN/$GENRAT/$METAGN/ 
$INHIBT/$FIXLST/$TLUA  INTGER/$NULTYP/// 

FORMST  =  FORM/FORMST  $$/  FORM/// 

FORM  =  COMP  /  FORM  COMP  /// 

COMP  =  SYNTYP/SYMSTG  /// 

IDENT  =  //  TLUAl  / 

GENDEF  =  $GSL. .  GNSIST  $$/GSL/// 

GNSIST  =  GENSTA/GNSLST  GENSTA /// 

GENSTA  =  CNOTTN  $,  SEQLST  $.  //  GENRAT/ 

CNDITN  =  KIND/KIND  PRDLST  /// 

KIND  =  $IF  SYNTYP/$IF  SYMSTG  /// 

PRDLST  =  $AND  PREDCT/PRDLST  $AND  PREDCT/// 

PREDCT  =  ZERTST/VTPTST/SYMTST/CPXTST/NRTST/SYNTST/// 
ZERTST  =  TRENAM  EQREL  ZERO/// 

ZERO  =  $0  /// 

SYNTST  =  TRENAM  COPULA  SYNTYP/// 

SYMTST  =  TRENAM  COPULA  SYMSTG/// 

CPXTST  =  TRENAM  $IS  HRDNES  /// 

HRDNES  =  $EASY  /$HARD//  FIXLST/ 

NRTST  =  NRTRE  $=  INTGER  /// 

NRTRE  =  $NR(  TRENAM  $)/// 
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VTPTST  =  VTPTRE  $=  INTGER  /// 

VTPTRE  =  $VTYP  (  TRENAM  $)  /// 

EQREL  =  $=  /  $  x=  //  FKLST/ 

COPULA  -  $=  /  $IS  //  FIXIST  / 

SEQI5T  =  $$$  SEQUEL/  SEQLST  $$$  SEQUEL/// 
SEQUEL  =  TRENAM  /  ACTI5T  /// 

ACTIST  =  ACT  /  ACTLST  ACT  /// 

ACT  =  IMPER  /  IMPER  $(  VELEST  $)  /// 

IMPER  =  $OUTPUT/  $LABEL  /$MINE/$SBT/ $COPY/ 
$PUTVLA/  $PUTVLB/$EXECUT/$OUTPOT/$BEGRTN  / 
$ENDRTN/$BEGRGN/$ENDRGN/$BEGLUP/$ENDLUP/ 
$BEGCND/$ENDCND/$PUTNAM/$PRTECT//  FKLST/ 
VBLIST  =  VBL/VBUST  $,  VBL  /// 

VBL  =  TRENAM  /  INTGER/  SETTEE  /  NRTRE/IDENT/// 
SETTEE  =  $TRUTH/$FALSTY/$!rRUTAB//  FKLST/ 
TRENAM  =  TREWLK /$LAST  (  TREWLK  $)/ 

$SELF  /  $NXTREE/// 

TREWLK  =  STEP/  TREWLK  $*  STEP  /// 

STEP  =  $FATHER/$LFTSIB/$RTSIB/$SONLST/ 
$TRUE/$FAISE/$SATLPT/$SONl/$SON2/ 

$S  ON3  /$S  ON4  /$S  ON5  /$S  ON  6/$S  ON7/ 
$SON8/$SON9/$SON10//  FKLST/ 

XLATER  =  LNGDEF  GENDEF/// 

/  BNF 
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GSL.  . 

IF  TYPDEF,  $LASEL  (SONl)  PUTVLA(6) 

$SON4  $PTJTVLB(30)  OUTPOT  $SON3. 

IF  SECPRT  AND  SON2  =  0,  $  FATHER. 

IF  SECPRT,  $SONl*SONl. 

IF  TAG  AND  SON2  -  0,  $PUTVLB  (NR(SONl)) 

$ RTS  IB  *  RTS IB. 

IF  TAG,  $PUTVLB  (NR(SONI))  PUTVLB  (NR(SON2)) 

$RTSIB  *  RTS IB. 

IF  FSTPRT  AND  SON2  x=  0,  $SONI  *  SONI. 

IF  FORM,  $SONI  $  RTS  13  *  RTS  IB. 

IF  COMP  AND  SONl  IS  SYNTYP  AND 

LFTSIB  =  0,  $  OUTPUT  (7,  0,  NR(SONl), 

FATHER  *  RTSIB  *  RTSIB,  RTSIB) 

$RTS1B. 

IF  COMP  AND  SONl  IS  SYNTYP, 

$OUTPUT  (7,  0,  NR(SONl),  0,  RTSIB) 

$RTSIB. 

IF  COMP  AND  LFTSIB  =  0, 

$  OUTPUT  (7,  1,  NR(SONl),  FATHER  *  RTSIB  * 

RTSIB,  RTSIB.)  $RTSI3. 

IF  COMP,  $OUTPUT  {7,  1,  NR(SONl),  0,  RTSIB) 

$RTSIB. 

IF  GENSTA,  $  SONl  $SON3. 

IF  CNDITN,  $SONl  $SON2  $  OUTPUT  (3,  0). 

IF  KIND  AND  SON2  =  SYNTYP, 

$  OUTPUT  (4,  NR(SON2)). 

IF  KIND,  $OUTPUT  (4,  0)  OUTPUT  (3,  3,  0,  NR(SON2)). 

IF  PRDIST,  $SON2. 

IF  PREDCT  AND  SONl  =  ZERTST, 

$SONl  *SONl  $OUTPUT  (3,  1,  NR(SONl  *  SON2)) 
$R!fSIB  *  RTSIB. 
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IF  PREDCT  AND  SONl  =  SYNTST,  $SONl  *SONl 

$OUTPUT  (3,  2,  NR  (SONl  *  SON3))  $RTSIB  *  RTSIB. 

IF  PREDCT  AND  SONl  -  SYMTST,  $SONl  *  SONl 

$OUTPUT  (3,  3,  NR(SONl  *  SON3))  $RTSIB  *  RTSIB. 

IF  PREDCT  AND  SONl  =  CPXTST,  $SONl  *  SONl 

$OUTPUT  (3,4,  NR(SONl  *  SON3))  $RTSIB  *  RTSIB. 

IF  PREDCT  AND  SONl  «  NRTST,  $SONl  *  SONl  *  SON2 
$OOTPUT  (3,  5,  NR  (SONl  *  SON3  ))  $RTSIB  *  RTSIB. 

IF  PREDCT,  $SONl  *  SONl  *  SON2 

$OUTPUT  (3,  6,  NR  (SONl  *,  SON3))  $RTSIB  *  RTSIB. 

IF  SEQI5T,  $SON2  SOUTPUT  (5,  2). 

IF  SEQUEL  AND  SONl  3S  TRENAM, 

$SONl  $  OUTPUT  (5,  0)  $R.TSIB  *  RTSIB. 

IF  SEQUEL,  $OUTPUT  (5,  1)  $SONl  $RTSIB  *  RTSIB. 

IF  ACTIST,  $  SONl  $OUTPUT  (1,  30). 

IF  ACT,  $OUTPUT  (1,  NR(SONl))  $SON3 
$RTSIB. 

IF  VBL.IET,  $SONl  $OUTPUT  (2,  0). 

IF  VBL  AND  SONl  =  INTGER, 

$OUTPUT  (2,  1,  NR(SONl))  $RTSIB  *  RTSIB. 

IF  VBL  AND  SONl  =  TRENAM  AND 

LFTSIB  *  LFTSIB  *  SONl  =  SETTEE,  $LFTSIB* 

LFTSIB. 

IF  VBL  AND  SONl  =  TRENAM,  $SONl 
$  OUTPUT  (2,2)  $RTSIB  *  RTSIB. 

IF  VBL  AND  SONl  =  NRTRE,  $SONl  *SON2 
$  OUT  PUT  (2,  4)  $RTS  IB  *  RTSIB. 

IF  VBL  AND  SONl  =  IDENT,  $OUTPUT  (2,  3,  NR  (SONl)) 
$RTSIB  *  RTSIB. 

IF  VBL  AND  SONl  =  SETTEE,  $RTSIB  * 

RTSIB  *  SONl  $  OUTPUT  (2,  5,  NR(SONl)). 

IF  TRENAM  AND  SON2  x=  0,  $PUTVLA  (1) 

$SON2  $EXECUT  (FILTRE). 


IF  TRENAM  AND  SONl  =  $NXTREE  ,  $PUTVLA  (3) 
EXECUT  (FILTRE). 

IF  TRENAM,  $PUTVLA  (0)  $SONl  $EXECUT  (FILTRE). 
IF  TREWLK,  $SONl  $PUTVLB(30). 

IF  STEP,  SPUTVLB  (NR(SELF))  $RTSIB  *  RTSIB. 

/GSL 


Appendix  I 

To  assist  the  reader  In  visualizing  the  syntactic  structure 
of  BNFGSL,  we  give  here  a  pictorial  representation  of  that  syntax: 


LEGEND 


SYMBOL 


PBimgLQM 

Enclosed  in  this  symbol  is  a  syntactic 
type  or  a  symbol  string. 

This  symbol  contains  the  name  of  a 
Involved  with  a  syntactic  type. 

This  symbol  contains  an  optional  syntactic 
type  or  symbol  string. 

Lines  or  rays  emanating  from  a  single  point 
denote  sequential  components.  Thu8« 

Z  QT  A  are  the  sequential  components  of  E. 

The  circle  denotes  an  OR  Junction.  Hare 
we  have'  A  or  B. 

This  symbol  denotes  the  beginning  of  a 
symbol  string. 


TLUA3 
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Appendix  II 


The  technique  described  in  this  report  has  been  tested 

experimentally  be  defining  the  translation  of  the  algebraic  language 

L  *  (into  IBM  7090)  in.  BNFGSL  and  bootstrapping  an  L  Translator  into 
^  o 

existence.  To  give  some  notion  of  the  appearance  of  the  BNFGSL  for 
a  conventional  algebraic  language,  we  append  a  listing  of  the  cards  which 
fed  that  bootstrap. 

Obviously,  the  named  "break-out"  codes  (arguments  of  EXECUT) 
and  the  VARITY  codes  used  in  VTYP  tests  are  not  self-explanatory,  but 
much  of  the  deck  may  be  readable,  and  the  approximate  level  of  effort 
involved  in  preparing  a  new  BNFGSL  deck  may  be  estimated. 


*G.  F.  Leonard,  "Introduction  to  the  CL-I  Programming  System",  with 
T.  E.  Cheatham,  Jr.,  et  al;  Technical  Operations,  Inc.,  TR-59-6, 
January,  1960. 


INIS  IS  A  C#RC  LiSlIKG  EV  C-E-I-P 


ltENT=//TLLAl , INVOKE/ 

JNUEP^//UL/!2t  INVf  KE/  - ^  ' — 

LCRTN  =  CIPI:EC  Lcercv/ZGINRAI/  V, 

*DCF=  1  +  /I-//FIJ(LSI  .INVOKE/ 

♦'IjLCP  =  1«/II///FIXLS1/ 

RblCF  =  lEC/HE.MLT/lLE/t6R/*GE//FIXLST/ 

VARfiLE  *  KENT  It  SUESCR  $)  /  ICENl/// 

SUeSCR  =  ASSPHR  /  ARilX  /// 

ARf  X-  lEPK/  ADCP  fFRN/  AREX  ACCF  TERR/// 
IEHR=F/CICR/IERR  RILCP  FACICR/// 

FAC rCR=VAktLE/lNTGER/$(  ARFX  S)/$(  ASSFHR  fl/// 
ASSPFiR  =  LP  ILS  T  APEX/// 

LPTLST=LPI/LPTI  ST  IPT/// 


LPT-VAPELE  1=/// 

IFPFR*IFCLS  LNCPFR  I./// 

IFCLS  =  IIF  eCGLEX  1,  /// 
eCCLEX*eCCIRR/6CrLEX  SOP  BCOIRR/// 

PCCTRR  =  ECCFAC/eCCTRM  SAND  BCCFAC/// 

PCPFAC  -  INCT  PCGPRR/8CCPRR/// 
eCCPPK  =  PELATN  /  fC  BCCLEX  S)  /  AREX  /// 

RELAIN  =  APEX  REt.CF  AREX/// 

0'NCPFR»6C  SLE/PINPHR/// 

PUNPFR»SLe  t./  IfSLE/PUNPHR  SUE  I./PINFFR  IFSUF/// 
sue  =  IDEM  ISi  PHRASE  /  PHRASE//ASSIGN/ 

PHRASE  =  SkPHR/EXPFR/CCNPHR/EULNFG/ASSFHP/GCPHP/ICENT/// 
FLLNEG  =  IaCT  IDEM/// 

CCNPHRs  SCCNECI  IDEM  ^  1C  IDEM///  '  ■ 

GOSUe»CCPFP/I;CEn^l  SS*  GCPHR/// 

GCPHR=»GOFART  ICEnT/// 

GCPARi  =  iGCit./s(:n/i  ir//F  ixlst/ 

EXPHR-IFX [ l//r iXi  SI/ 

SWPHR=  tSkllCH  $(  ARtX  $,  ICLIST  $)/// 

ICLISI  =  irCCMP/fCL  11  I  IDCCKP/// 

ICCCPP=ICENI  S./ICEM///  V 

IFSUE-  IFPFP/  ICENl  fS*  C FPHR// INH I ET / 

STATE  -  IFSL0/CECLAR/SUE  $.//GENRAT/ 

I CCCCE=STATE/LCCCCE  STAfC/// 

LCeCCY  =  SEGNLCi/  LCCCCE  $S/INCLC/// 

CURCEC  =  SRCUTIN  I C EN T//N E TAGN/ 

GECLAR  »  TELITF  /  TPlCEt.  /  RCNCCL  /  RTNHEC  //  GENPAT  / 
NULL  -  //Ml.  lYF/ 

GLCePH  ^  ICLCHAL  l(  (NltlK  i)  /KirPAl/// 

AirSTF  ^  SLl'CAl  /Cl  Cl'Ph/M'l  I  /// 

RINHEi:  =  ICENT  SPIN  ALi.SIF  H$//PEIAGN/ 

IDLHEr.  --  1TAELE  H  EM  IMG  R  ALC'TF  S$S  ieEGIK//PE  lAGK/ 
lELlTR  =  SifEM  IDEM  IMGER  IMGER  INTGER  1  SI  / /B&1*ACN/ 
TBLITL  =  TELITK  lENC/Tf^LITR  TBLTTL/// 

TBLCEC  =  TELHEC  TBLITL/// 

nCNCCL  ^  IPECRGN  /  SENCPGN  //  F  IXLST,  PFfAGN  / 

/BNF 
LSI  .. 

IF  SUEJCP,  ISDN!  SPU I VL A ( NR  I LF I S I B ■ LF 1 1  I P )  I 
EXELUK  IM  IPI  )  PUTVLAIPiPYCIV)  FUlVLBd) 

PUIVLBISCNI)  EXECUr  (GVCCCN)  CUIPCT  EX  ECU  I  ( RUNCEJIi 


ruifri  SLFisJe  ipurviec self )  rijFVLe(iFiS‘ifru^«lj%l«M$^ 

ILJISIP  irXEClJI  (FPRTCN)  FXECUT  (NRBICK  )  . 

IF  S!AJF 

IF  15  '-.le  AKL  SCN;'*C,.fSCM'.'' 

(F  IFSLd.SLAEbL  (SOM)  1SGN3. 

IF  IFPFR  AKC  NR(S0N1*SCN2)-*  1  AAC  SCM  •SCK'2«SCN1«SCN2  X=  C 
i  SCM  S  SCN2*SrM  $  fKCCNC  . 
i  J  1 E  F. <■  CN 0 3 S ON2 «  S r N  1  ^ 

IF  cr  r  (  f  y  ,  ircPV  (TRO  IAB,FA1HER  )  *£CM. 

IF  BCriRP  ANC  LFISIE^O  •  RTS  = 

SCCPV  (  TRLirAe.FAIhER)  »S0N1. 

IF  BCCTRP  ANC  L  FT  S  I  P»0,  $CCP.Y (  TaUXlH»-E.AJ.HERJ _ ^ 

SET  (f  ALSTY,RTSIE*Rf£TB)  iSCM  IBEGCNC 
fR^SIE^>RTSIe. 

IF  eCOIRP  ANC  RTSie»Ct*COPYITRljTAB, FATHER)- 
fSCNl  TENDCND. 

IF  ECCTRP.JCCPY  (TRUTH, FilXHE.RL  5ETIF 
RTS  I®ai-)J  T'5"rE'V  *  S  CNl^ 
i  F  BCCiFAiC  ^18?NO“  I  F  T  S  I  B*0  A^^f)^’!^^i 

'  J C  C  P Y (  1 RU I A  e , F  A  T  HER  )  »SON2  ’  $  S  OK  1 
IF  eOOFAC  ANC  L F f S I e»0, SCCPY ( FALS T V , F A IHER ) 

SET ( TRL  rh,RTSIB«RTSI6)  SSCN2 » SCNl SBEGCKO 
$RTSie«RTSIB. 

IF  fiOCFAC  ANC  R75IE  =  0  ANC  NR ( FATHER«F ATHER )  »  1 
&ANC  FAT):;ER*FATHEfi*FATHER  IS  IFCLS, 

I  CCFY(TRLTAE,  FATHER)  *  SCN2  *  SOM  . 

WfflIPW  m 


♦F-^ee^FifCI !>t  Hju siE«iLTSi e V  cof V I f WT 

FA  IHEl*)  ♦SCN2  ISCNl  IRTST B«R  T ST fi  i  * 

IF  8CCFRP  AND  L F I  S I  6  =  0 , ACOPY ( TRUT AB , F A  I  HE R ) 
tSCNl. 


—46*  T+FE  fHHffPbf '  i'T-Atl^r'ftVFlT^n  .  '  " 

IF  AREX  ANC  SELF  IS  FARC  ANC  FATHER  IS  ECEPRP  ,  ISCM  i  PINE 
♦eUTFUT  (RFLATC,  I,  SELF,  C,  F ATHER •TRt E ,  ■  F A 1  HER  •  F A L S F )  . 
IF  AREX  ANC  SELF  IS  HARC,$SCN1  IMNE. 

IF  AREX  ANC  FAIHFR  IS  eCCPRM  ,  t  SCNl 
4*if»t#PljT  (RELATE,  I ,  SON  I-.,  0 ,  FAT  HER" 

^lp•^HlRt.X,■■■^^f.CNl.  ,  ,u.,.  I  I,  „i.i. 

IF  PUKFH'-R-vT'S-GNl": . . 

IF  SUE  AKC  SCN2=0,ISCN1«SCN1  TRTSrE.*RTi;t:,;1^^tjj^3^  _■ 
IF  SUE,$LAEEL(SCN1 )  $S0N3«S0N1  IRTS IB*R tS IE . 

SNPH  R^  <CUTPUT(  SMTCH,  SCN3  , 

Lfe  ICCCIf^,|CUTFUT(SKrRA,SPHl)  SRTSIE.  . 

IF  EXPHR,  lEEGPGN  CUIPUKEXII)  ENCRGN.  ^ 

PF  C C N  P ITR  , .  ,XaUT^P3I.T  ( 

IF  GfiPHR,  ICUIPU  r(  TRANS, SCN2)  . 

IF  GLSLB  ANC  SCN2  X*  0,  SLAEEKSCM)  $SCK3. 

IF  GCSLE,  SSONl. 

I«  AS5F»R.,-$S0N2  $ P 

IF  LPTLST,ISCN1.  ^ 

IF  LPT,  SSCNl  IRTSie. 

IF  VARELE  ANC  S0N3  =  C  ANC  VTYP(SCM)=3  ANC 

FATHER  IS  LPT,  ACUTPUT  (  STORE  ,  SOM  ,  F  ATHE  R  «  FA  T  H  ER  «  R  T  S  I  B  )  . 
IF  VARELE  AND  SCN3«C  ANC  VTVPISCM)«A  ANC 

«  .ratitrfN  tc  w  »r  ^  r  n  #cr'iki«  ^ 


.ratitrfN  tc  w  »r  ^  r  n  #cr'iki«  *m  t%«t 


.  r"'i-  /i  i\  f  V I  j  .-"c  A"i\  I  TTl[TTSrriTT~T’r‘’  - - - - — ™' 

'  'i.  !  H'tiVLLMl)  tiCM  tVufVLAJPLr)  ISCM 

ri  .  j  V  LlrV.rAThURtFA  r»-ER*RTSie  )  $SCM. 

■''*''■11:  !i\'l  SCN3  X  =  0,  SS0K3  ICtTFCT. 

II  'jAHELE  ANi.  FATHER  IS  LPT,  ICL'T  PUT  (  STCRE  ,  SCN 1  , 

I  A  )hEk«r-A  {  !•  Ei?  «R  TSn!  ). 

IF  K  ANC  RTSIL'  IS  SUBSCR  AK-C  FAThER«F/THER  IS  FACTCR, 
»PLIVLE(C)  SRTSId  $PUTVLA(6ET)  JRTSIE  iRlSIE. 

IF  Jt  ANC  RTSie  IS  SUBSCR, 

tPLTVLE(l)  SRTSie  JPUTVLA(PtT)  SRTSIE 

1!  L  f  VLe(FAIHr-P«FAThER*FATHER*RTSlE  J  JRTSIE. 

If  t)  AFiC  V  rvP(  LF  1  S  ie*LFTSTR*LFTS  IE  )  =  3, 
tPLTVLE(C)  EXEr.UKACf  VCN)  ILFTSIE. 

!F  t)  ANC  V ( YP( LF IS ie«LF T £ie«LFT£  IE  )=4, 

IPLfVLEd)  PUTVLE(C)  EXECUTI ADT  VCN )  ILFTSIE. 

IF  %(  ,$RTSie. 

IF  TERF  ANF  SELF  IS  FARC,$SCN1  IRIKE  ILFTSIB 
I R  1  S  1  E  •  P  T  S  I  B  . 

IF  IfRF.ISLM  IL.TSIB  SR  1  S  I  P»R  I  £  I  B  . 

IF  Ai;r.F  ANC  LFISie-C,  SRTSIB  SC  U 1  PL  T  (  S 1 GK  ,N  R  I  SE  IF  )  ,  PT  S 1 B  ) 
SRISIB«RISIB»RrSIE. 

IF  ACCF.SGLTPUI I  ACC  SUB , NR  I  SELF ) ,L AS T I LFT S  I E -LFT S  1 B  )  , 

RI5IP)  $RTde*PTSI8«R  TSIE. 

IF  FACIGP  AFC  SELF  IS  HARC.SSCM  SPUE 
ILETSIF  SRISlB«RTStB. 

IF  FAClCRflSCNl  ILFTSIB  SRT  S  I  e«RT  S I B  .  /' 

IF  RULtP,ICUTPir(NFYLlV,NRISELF),LAST(LFTSIE« 

LFTSIEliFirSIB)  IRrSIB-RTSIB-RTSIB. 

IF  ICEFT  AM  VTYP(S£1,F)  =  7,  ICUTPl  T  I  FUNC  ,  SEL  F  ) . 

If  IIFFI  AM.  FA  If  FI  15  ECCPRP,  If  U  !  PU  T  (  RF  L  A  I  F  ,  1  , 

Sf  If  ,C,I  Alf  r«*lHl  E,FAII-EU*FAl  St  ). 

II  ICFFI  AFC  FAIhtR  IS  VARBLE,  SPUI  VI.  A I  SELF  )  EAECtlllNIIPl) 
PUIVLAIlOCA IE  I  SFAThER  lEXECUT I HC SKYP )  PtlVLEIl) 

piiviek;)  fxeclt(actvcn)  nuipci  ifatfer  sfitvlb (self) 


*  IF  X  E  C  U  li  ( /V  C  C  CO  N  )  IW  E  R  S  EC  t’  1 1  F  B  E  T  C  N  )  E'XECirWfiEl,P^  I 

i.Uff'l.  T.  (  "'■'  ' 

I!  .CEf'f,  SLbTPUriSTCRE,SELF,l). 

‘!l'L^EG,  ;$Cli7PUT(STORE,SCN'Wk#.J 

i;  I.CRIN,  lENCRTN.  _ _ 

IF  CURLEC,  $PUTVLA(NR(SCN2) )  EXECUT  (KYPTtC  )  EEtf^T 
IF  leii  FR,fPLlTVLA(KR(  SON2)  )  PUT  VL  B  ( NR  (  £CX  3  )  > 

P U T  V  L  e  C  NR  (  S  dlN  A‘  )  I  WT VLB  ('*IR  (  St^5  »T:-wyE1l>>l!RMililillEJ.1.DC ) 

IF  TBLEEC  AND  S0NA«SCN1  *  GLCBPH, 

I P  L  T  V  L  A I N  U  BUT  Vi 

P  U  i  V  LE  ( NR  (  S  CNA  •  SCN  l  •SONr 
IF  TELEEC, 

SPLTVLA (NR(SCN2 U  PUTVLBiBI  PUTVLB (NR ( 5CN3 1 1 
PUTVLEiC)  EXECUTiTABLOCI. 

IF  RGNCCL  AND  NRiSE-LF-I 
IF  RGNDCi-yY.:.j|.^^ERGN  .  ^  '  v- ■  .  'i-'  '  ' 

IF  R  INF  EC  AND  SCNiftSCNl 

SPLTVLAiNRiSCNl  ))  PUTVLB(2) 

PUlVLE(^R(SCN3^iSCNl•SC^3n  EXECUT  (HTNCEC  ). 

IF  RTNEECt 

tPLTVLAiNKiSnNl  I)  PUTVLBIl)  PUTVLB(C)  E XECt'T CR1 NCEC 

/GSL 
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